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Abstract 

Replicated  architecture  has  been  proposed  as  a  way  to  obtain  acceptable 
performance  in  a  multilevel  secure  database  system.  This  architecture  contains 
a  separate  database  for  each  security  level  such  that  each  contains  replicated 
data  from  lower  security  classes.  The  consistency  of  the  values  of  replicated 
data  items  must  be  maintained  without  unnecessarily  interfering  with 
concurrency  of  database  operations.  This  paper  provides  a  protocol  to  do  this 
that  is  secure,  since  it  is  free  of  covert  channels,  and  also  ensures  one-copy 
serializability  of  executing  transactions.  The  protocol  can  be  implemented  with 
untrusted  processes  for  both  concurrency  and  recovery. 


1.  INTRODUCTION 


In  recent  history,  significant  energy  has  been  expended  in  attempts  to 
develop  database  systems  that  protect  classified  information  from 
unauthorized  users  based  on  the  classification  of  the  data  and  the  clearances  of 
the  users.  These  are  generally  referred  to  as  multilevel  database  systems. 
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Earlier  efforts  to  develop  this  kind  of  database  system  utilized  the 
integrity  lock  approach  [4]  or  the  kernelized  DBMS  approach  [8,10].  The 
former  approach  relies  on  a  trusted  front-end  process  that  applies 
cryptographic  check  values  to  data  in  an  untrusted  back-end  database.  The 
latter  approach  relies  on  decomposing  the  multilevel  database  into  single  level 
databases  that  are  stored  separately.  The  data  must  be  recomposed  to  obtain 
multilevel  data  in  response  to  queries. 

The  integrity  lock  approach  is  computationally  intensive  and  has  a 
potential  covert  channel  [4].  There  is  also  a  risk  that  service  could  be  denied  by 
forcing  checksums  to  fail  continuously.  The  kernelized  approach  can  yield 
reduced  performance  due  to  the  need  to  recombine  single  level  data  to  produce 
multilevel  data.  More  recently,  a  replicated  architecture  approach  has  been 
proposed  with  the  speculation  that  performance  degradation  due  to  security 
requirements  would  not  be  as  severe  as  with  the  other  approaches  [5]. 

Basically,  the  replicated  architecture  approach  uses  a  physically  distinct 
back-end  DBMS  for  each  security  level,  with  each  one  containing  all  the  data 
at  its  security  level  and  below.  The  system's  security  is  assured  by  a  trusted 
front-end,  that  permits  a  user  access  to  only  the  DBMS  that  matches  their 
security  level.  In  this  approach,  some  of  the  less  desirable  features  of  the  other 
approaches  are  avoided  but  at  a  cost.  The  cost  is  that  of  maintaining  the 
consistency  of  the  data  that  is  contained  in  more  than  one  back-end  database 
(almost  all  of  it)  without  compromising  security  or  losing  the  potential  for 
concurrent  execution  of  database  operations.  The  problem,  then,  is  to  develop  a 
protocol  that  does  this  "correctly",  i.e.,  so  the  user's  view  is  that  of  a  single 
database  running  only  the  user's  transactions  in  some  sequential  order. 

A  number  of  protocols  have  been  developed  for  kernelized  architecture 
multilevel  database  systems  that  can  be  adapted  to  the  replicated  architecture 
ones.  A  protocol  using  a  trusted  scheduling  process  is  proposed  in  [7],  and  an 
untrusted  one  in  [9],  Both  of  these  utilize  a  timestamp  ordering  technique  with 
a  global  "clock"  that  makes  them  potentially  susceptible  to  a  covert  channel, 
depending  on  how  the  "clock"  is  implemented. 

For  the  replicated  architecture  multilevel  database,  a  transaction 
processing  protocol  is  presented  in  [6],  This  protocol  uses  a  trusted  queue 
manager  in  its  scheduler.  In  addition,  the  protocol  fails  unless  the  security 
levels  are  linearly  related.  It  is  interesting  that  this  protocol  has  been  adapted 
to  a  kernelized  architecture  model  [10].  In  [6],  it  is  also  noted  that  although 
the  architecture  appears  to  be  that  of  a  distributed  database,  the  standard 
techniques  used  for  consistency  control  in  such  systems  fail  due  to  the  security 
requirements  imposed.  For  example,  the  classical  two-phase  commit  protocol 
has  a  covert  channel,  the  capacity  of  which  is  computed  in  [3].  Concurrent  with 
the  work  presented  here,  another  approach  to  this  problem  using  fully 
replicated  transactions  has  been  explored  in  [12]. 

In  this  paper,  a  scheduling  protocol  for  the  replicated  architecture  will 
be  defined  that  relies  solely  on  untrusted  processes,  does  not  require  a  linear 
ordering  of  the  security  levels,  and  does  not  rely  on  timestamp  ordering 


methods.  The  criterion  for  "correctness"  that  is  brought  to  bear  is  drawn  from 
the  standards  used  in  the  theory  of  replicated  database  systems,  namely  one- 
copy  serial  izabi  I  ity. 

The  presentation  is  organized  as  a  description  of  the  model  used, 
followed  by  the  specification  of  the  protocol,  the  proof  of  its  correctness, 
remarks  about  garbage  collection  and  recovery,  the  conclusion,  and  directions 
of  future  work. 


2.  THE  MODEL 


The  security  model  used  here  is  based  on  the  framework  established  by 
Bell  and  LaPadula  [1].  The  notation  for  the  security  and  the  replicated 
architecture  database  model  is  adapted  from  that  in  J  ajodia  and  Kogan  [6]. 
Both  are  sketched  in  the  following  sections. 


2.1  Security  Paradigm 

The  database  system  (DBS)  consists  of  a  finite  set  D  of  data  items  that 
are  objects  of  the  trusted  system,  and  a  finite  set  T  of  transactions,  that  act  on 
behalf  of  users  and  are  subjects  of  the  trusted  system.  There  is  a  lattice**  S  of 
security  classes,  (S,<).  If  security  classes  u  and  v  are  in  S  then  u  dominates  v 
if  v  <  u.  There  is  also  a  labeling  function  L  that  assigns  unique  security 
classes  to  data  items  and  transactions: 

L:DuT  S 

The  notion  of  security  here  only  encompasses  mandatory  access  control 
requirements.  Discretionary  access  control  issues  are  not  discussed.  The 
mandatory  access  control  requirements  are: 

(1)  If  transaction  Tj  reads  data  item  x  then  L(Tj)>L(x). 

(2)  If  transaction  Tj  writes  data  item  x  then  L(Tj)=L(x). 

E  nforcement  of  these  two  conditions  guarantees  that  information 
concerning  high  security  level  data  items  cannot  flow  to  lower  security  level 


It  is  not  necessary  that  the  security  classes  form  a  lattice.  A  partially  ordered 
set  is  sufficient,  though  the  lattice  case  is  easier  to  comprehend  intuitively.  In  the 
description  of  the  protocol,  the  necessary  addition  to  protocol  to  extend  it  to  this 
case  is  noted. 


transactions  (and  users).  The  second  condition  is  more  restrictive  than  the 
traditional  ★-property  in  that  Tj  cannot  write  data  item  x  if  L(Tj)<L(x),  i.e.,  no 
write-ups  are  permitted.  I  n  [6],  it  is  argued  that  write-ups  are  undesirable  in 
trusted  database  systems  for  integrity  reasons  and  may  permit  covert 
channels.  In  any  case,  the  restriction  on  writing-up  is  imposed  to  bound  the 
complexity  of  the  protocol,  and  can  be  removed  at  the  cost  of  an  increase  in  the 
complexity  of  the  model  definition  and  the  attendant  protocol. 


2.2  DBS  Architecture 

The  replicated  database  architecture  is  obtained  by  adding  a  collection  of 
single-level,  untrusted  database  systems  to  the  security  structure,  one  for  each 
security  class.  That  is,  by  adding  a  set  {Cv  ve  S}of  back-end  databases.  The 
system  also  contains  a  front-end  processor,  the  trusted  front  end  (TFE),  that 
mediates  the  access  of  subjects  (transactions)  to  objects  (data  items).  The  TFE 
will  contain  the  trusted  computing  base  (TCB),  but  not  all  of  the  TFE  need  be 
trusted.  In  particular,  much  of  the  scheduling  mechanisms  for  the  protocol  will 
be  in  the  untrusted  portion  of  the  TFE. 

Each  database  Cv  contains  copies  of  all  data  items  in  all  databases 
whose  security  level  is  dominated  by  v.  The  copy  of  data  item  x  in  the 
database  Cu  is  denoted  by  xu.  Alternatively,  if  L(x)=u  so  xe  Cu,  there  is  a  copy 
of  x  in  each  database  whose  security  level  dominates  u. 


2.3  Transaction  Model  and  Concepts 

A  database  transaction  is  the  execution  of  a  set  of  atomic  operations  on 
the  data  items  of  the  database.  The  operations  permitted  on  the  data  items  are 
Read(x),  that  returns  the  value  stored  by  the  data  item,  and  Write(x),  that 
changes  the  value  of  the  data  item  to  a  specified  value.  Other  transaction 
operations  such  as  Start,  Commit,  and  Abort,  while  significant  for  the  control 
of  transaction  processing  [2],  need  not  be  made  explicit  for  communicating  this 
protocol.  In  fact,  only  committed  transactions  will  be  considered  in  defining  the 
protocol.  If  Tj  is  a  transaction,  then  a  Read(x)  operation  by  Tj  is  denoted  r^x], 
and  a  Write(x)  operation  by  Wj[x]. 

The  atomicity  of  the  transaction's  operations  ensures  that  the  DBS 
behaves  as  if  it  executes  the  operations  sequentially  even  though  it  may  do  so 
concurrently.  The  transaction  model  reflects  the  possibility  of  concurrent 
execution  in  the  following  definition. 

Definition  A  transaction  Tj  is  a  partially  ordered  set  with  ordering  relation  <j 
where 


(1)  Tj  e  {rj[x]  xe  D}u  {Wj[x]  Xe  D} 


(2)  If  rj[x],  WjCxleTj,  then  either  r;[x]<;  Wj[x]  or  W;[x]^  r^x]. 


The  definition  requires  only  that  operations  on  the  same  data  item  be 
ordered.  Two  operations,  from  perhaps  different  transactions,  conflict  if  they 
operate  on  the  same  data  item  and  at  least  one  of  them  is  a  Write.  Operations 
of  several  transactions  can  be  commingled  so  that  concurrency  of  execution  can 
be  extended  to  sets  of  transactions,  as  reflected  in  the  following. 

Definition  A  complete  history  H  over  a  set  of  transactions  T  =  {r1;  T2, - , 

Tn}is  a  partial  order  with  ordering  relation  where 

(1)  HdTjuT2u - u  Tn 

(2)  ^  a  <i  u  <^u - u  S, 

(3)  If  p,  q  are  operations  of  H  that  conflict,  then  either  p<^,  q,  or  q<^,  p. 

Since  only  complete  histories  will  be  considered,  they  will  be  referred  to 
simply  as  histories. 

The  preceding  view  of  transaction  processing  is  the  view  of  the  user,  to 
whom  replicas  or  versions  of  data  items  are  transparent.  Histories  of  this  type 
will  be  called  one-copy  histories  when  it  is  necessary  to  distinguish  them  from 
histories  that  represent  the  system's  view  of  a  transaction  and  that  deal  with 
copies  of  data  items. 

When  a  set  of  transactions  is  executed  by  a  replicated  DBS,  an 
operation  in  a  transaction  must  be  translated  into  the  equivalent  operation  on 
some  or  all  of  the  copies  of  the  data  item.  A  translation  function  h  performs 
the  mapping.  For  a  Read(x),  h  determines  the  copy  of  x  to  be  read,  i.e., 
h(ri[x])={i'i[xu]}for  some  u.  For  a  Write(x),  h  determines  what  copies  of  x  are 

to  be  updated,  i.e.,  h(wi[x]={wi[xa],  Wj[xb], - }.  I  n  the  case  at  hand,  if 

L(Tj)=u,  then  h(rj[x])={ri[xu]},  and  h(wi[x])=^/i[xv]  v>u}. 

The  concept  of  a  replicated  data  history  is  needed  to  represent  the 
actions  of  the  translated  transactions  on  the  replicated  data.  I  n  the  replicated 
architecture,  two  operations  on  data  items  conflict  if  they  operate  on  the  same 
copy  of  the  data  item  and  at  least  one  of  them  is  a  Write.  I  n  the  following 
definition,  Oj[x]  represents  either  a  Read(x)  or  a  Write(x)  operation. 

Definition  A  replicated  data  history  H  over  a  set  of  transactions  T={T1;  T2, 
- ,Tn}is  a  partial  order  with  ordering  relation  such  that 

(DH^TJuh^u - u  h(TJ 

(2)  I f  rj[x]^  Oj[y]  in  Tjf  then  h(r,[x]K  p  for  all  peh(Oj[y]) 

(3) 1  f  Wj[x]<;  Oj[y]  in  Tj;  then  W;[xu]<^,  OjtyJfor  all  ueS  such  that 

Wj[xu]e  h(Wj[x])  and  Oj[xu]e  h(Oj[y]) 


(4)  If  p,  qe  H  and  they  conflict,  then  either  p<q  or  q<p 


It  should  be  noted  that  this  definition  is  not  as  restrictive  as  that  in  [2], 
and  though  not  necessary  for  this  paper,  all  the  results  there  appear  to  hold 
under  this  weakened  definition. 

Replicated  data  histories  represent  the  execution  of  a  set  of  transactions 
as  seen  by  the  entire  MLS-DBS  rather  than  as  seen  by  the  user,  to  whom 
copies  of  data  items  are  transparent.  Notice  that  such  histories  preserve  the 
orderings  stipulated  by  the  transactions  (conditions  (2)  and  (3)). 

The  concepts  of  reads-from  and  final  write  are  essential  to 
understanding  the  relationships  among  histories  over  the  same  set  of 
transactions.  These  may  be  defined  for  one-copy  or  replicated  data  histories. 

Definition  Let  H  be  a  history  (one-copy  or  replicated  data)  over  a  set  of 
transactions  T. 

(1)  Tj  reads-x-from  Tj  in  H  if  W;[x]<^  r^x]  and  there  is  no TkeT  for 

which  Wj[x]<j_|  wk[x]<j_|  i-jtx] 

(2)  Wj[x]  is  a  final  write  of  x  in  H  if  there  is  noTkeT  for  which  WjCx]^ 
wk[x] 

This  definition  clearly  makes  sense  for  one-copy  histories,  and  does  also 
for  replicated  data  histories  if  applied  to  a  single  copy  of  a  data  item.  That  is, 
"Tj  reads-xu-from  Tj"  and  "Wj[xu]  is  a  final  write  of  xu"  are  meaningful.  These 
concepts  are  used  to  define  the  notion  of  equivalent  histories. 

Definition  Let  H  and  G  be  histories  of  the  same  type  (one-copy  or  replicated 
data)  over  a  set  of  transactions  T.  H  and  G  are  view  equivalent  if  they  have 
exactly  the  same  reads  from  relationships  and  the  same  final  writes. 

Correct  execution  of  a  set  of  transactions  should  appear  to  the  user  as  if 
the  transactions  were  executed  one  at  a  time  in  some  order.  This  concept  of 
correctness  is  formalized  as  follows. 

Definition  A  history  H  is  serial  if  for  every  pair  of  transactions  Tj;  Tj  of  H, 
either  all  operations  of  Tj  appear  before  all  those  of  Tj,  or  vice  versa.  A  history 
H  is  serializable  if  it  is  view  equivalent  to  a  serial  history. 

Any  protocol  for  processing  transactions  on  a  replicated  architecture 
database  may  give  rise  to  a  replicated  data  history.  This  history  will  represent 
a  "correct"  execution  of  the  transactions  if  it  appears  to  the  user  that  the 
transactions  executed  serially  on  a  one-copy  database.  Therefore  a  notion  of 
equivalence  between  a  one-copy  history  and  a  replicated  data  history  is 
necessary.  This  requires  the  following  definitions. 


Definition  If  H  is  a  replicated  data  history,  sayTj  reads-x-from  T;  in  H  if  for 
some  ue  S,  Tj  reads-xu-from  Tj. 


Definition  Let  H  and  H1C  be  replicated  data  and  one-copy  histories, 
respectively,  over  the  same  set  of  transactions  T.  H  and  H1C  are  equivalent  if 

(1)  H  and  H1C  have  the  same  reads-from  relationships,  i.e.,  Tj  reads-x- 
from  Tj  in  H  if  and  only  if  Tj  reads-x-from  T;  in  H1C. 

(2)  For  each  final  write  Wj[x]  in  H1C,  Wj[xu]  is  a  final  write  in  H  for 
some  ue  S. 

Definition  A  replicated  data  history  H  is  one-copy  serial izable  {1SR)  if  it  is 
equivalent  to  some  one-copy  serial  history. 

One-copy  serializablility  is  the  criterion  for  "correctness"  that  will  be 
applied  to  protocols  for  transaction  processing  in  a  replicated  architecture 
database.  The  protocol  to  be  described  herein  yields  replicated  data  histories 
that  are  one-copy  serializable. 

T o  complete  the  specification  of  the  model,  the  update  projection  U;  of  a 
transaction  Tj  is  defined  as  {Wj[x]  Wj[x]eTj}.  For  each  transaction  Tj,  U;  can 
be  regarded  as  a  transaction  that  must  be  executed  at  each  database  Cu  for 
which  u>L(Tj),  in  order  to  propagate  the  updates  generated  by  Tj  to  copies  of 
the  data  items  affected.  In  particular,  each  transaction  T;  on  the  replicated 
database  can  be  decomposed  into  a  primary  transaction  that  acts  on  Cu  where 
u=L(Tj),  and  its  update  projection  U;,  that  acts  on  Cv  for  v>L(Tj).  It  is  often 
useful  to  think  of  a  primary  component  or  an  update  projection  as  a  one-copy 
transaction  acting  on  a  single  back-end  database.  Two  update  transactions,  or 
an  update  transaction  and  a  primary  transaction  conflict  if  their 
(non replicated)  parent  transactions  conflict.  It  should  be  noted  that  write-up 
transactions  could  be  allowed  by  modifying  the  definition  of  an  update 
projection  to  include  the  write-up  operations.  The  extension  of  the  model  and 
the  protocol  to  this  case  is  quite  complicated  and  including  it  adds  a  measure 
of  complexity  that  would  only  obscure  this  exposition,  and  will  be  given  in 
detail  in  a  future  paper. 


3.  DESCRIPTION  OF  THE  PROTOCOL 


The  problem  is  to  define  a  protocol  for  executing  the  primary 
transactions  and  the  update  projections  in  the  "correct"  way.  As  previously 
mentioned,  a  protocol  will  be  considered  "correct"  if  the  resulting  replicated 
data  history  is  one-copy  serializable. 


I  n  the  following,  the  symbol  <  wi  1 1  be  used  for  all  order  relations  (on  the 
security  lattice,  transactions  and  histories).  The  intended  order  relation  will  be 
clear  from  the  context  in  which  it  is  used.  The  notation  Tj  will  be  used  for  both 
the  entire  transaction  on  the  one-copy  database  and  its  primary  component  on 
the  back-end  database,  with  the  context  again  the  arbiter. 

The  protocol  is  a  variant  of  the  traditional  primary  site  algorithm  [2]. 
Each  back-end  Cu  will  have  a  scheduler  Pu  that  produces  view  serializable 
schedules  for  the  transactions  executed  there  (primary  components  and  update 
projections).  In  addition,  Pu  must  preserve,  in  its  serialization  ordering,  the 
order  in  which  it  receives  update  transactions.  There  are  several  types  of 
schedulers  that  accomplish  this,  among  which  are  variants  of  conservative  two- 
phase  locking  and  conservative  timestamp  ordering  protocols  [2].  Pu  need  not 
be  trusted. 

I  n  fact,  if  one  has  decided  on  a  primary  site  type  of  protocol,  and  has 
decided  that  correctness  is  represented  by  one-copy  serial izabi I ity,  then  one  is 
locked  into  a  particular  approach  to  specifying  the  protocol,  at  least  in  the 
most  abstract  sense.  Once  a  serialization  order  between  transactions  and/or 
update  projections  has  been  established  at  some  back-end  database,  the  same 
order  must  be  maintained  between  the  update  projections  at  all  higher  security 
level  back-end  databases,  else  one-copy  serializability  is  not  enforced.  If  update 
projections  could  be  executed  a  at  high  security  level  back-end  before  they 
were  executed  at  some  lower  level  back-end,  a  serialization  order  could  be 
established  at  a  high  level.  Since  this  serialization  order  cannot  be 
communicated  downward  without  violating  the  security  policy,  such  behavior 
cannot  be  permitted.  Therefore  update  projections  must  be  propagated  to 
higher  level  back-end  databases  in  an  order  consistent  with  that  of  the  security 
lattice.  Thus  the  previous  assumption  on  the  behavior  of  schedulers  (or  some 
other  means  of  preserving  serialization  orderings)  is  necessary.  It  follows  from 
this  discussion  that,  under  these  assumptions,  specifying  the  protocol  amounts 
to  specifying  the  means  by  which  update  projections  are  propagated  upward 
through  the  back-end  databases. 

A  list  Qu  is  associated  with  each  back-end  database  Cu.  The  purpose  of 
Qu  is  to  maintain  a  list  of  the  primary  transactions  and  update  projections  that 
have  been  executed  and  committed  at  Cu.  The  list  is  ordered  by  the 
serialization  order  of  the  execution  of  these  transactions,  which  need  not  agree 
with  the  order  in  which  transaction  are  actually  executed  or  committed.  The 
Qu  are  used  to  make  the  correct  order  of  execution  at  lower  security  level  back¬ 
end  databases  available  to  those  at  higher  security  levels. 

In  addition,  there  is,  for  each  ueS,  an  untrusted  mechanism  Ru  that 
maintains  Qu  and  can  read  the  contents  of  Qv  for  all  v<u  and  is  considered  to 
be  part  of  the  global  scheduler. 

The  actual  location  of  theQu  or  Ru  is  not  important  for  the  correctness 
of  the  protocol,  but  since  any  access  to  them  must  be  monitored  by  theTCB,  it 
is  most  efficient  for  them  to  be  within  the  untrusted  part  of  theTFE. 


One  additional  concept  is  necessary  prior  to  describing  the  protocol.  Say 
a  back-end  database  Cu  covers  Cv  if  L(CU)  covers  L(CV)  in  the  security  lattice. 
(Recall  that  u  covers  v  in  a  lattice  if  u>v  and  there  is  now  for  which  u>w>v.) 

The  protocol  works  basically  as  follows.  A  transaction  is  submitted  to  the 
TFE  which  dispatches  it  for  execution  to  the  back-end  database  with  the  same 
security  class  as  the  transaction.  The  primary  transaction  is  executed  and 
committed  there,  and  the  update  projection  is  added  to  Qu,  where  u  is  the 
security  level  of  the  transaction.  The  update  projection  is  then  promulgated  to 
the  back-end  databases  for  which  the  security  class  strictly  dominates  that  of 
the  transaction.  The  distribution  and  timing  of  the  update  projections  is 
controlled  by  the  untrusted  process  Rv  for  v>u.  If  Cv  covers  Cu,  Rv  can  scan 
Qu,  retrieve  an  update  projection,  and  dispatch  it  to  the  scheduler  at  Cv.  The 
crucial  part  of  the  protocol  is  in  specifying  the  rules  for  retrieval  of  an  update 
projection  by  Rv.  If  not  done  correctly,  the  resulting  histories  will  not  be  1SR. 

Notice  that  each  Cu,  in  isolation,  can  be  considered  to  be  a  one-copy 
database.  Primary  transactions  with  security  level  u,  and  update  projections 
from  transactions  whose  security  level  is  dominated  by  u  can  be  considered  as 
transactions  on  this  one-copy  Cu.  Therefore,  the  concepts  of  scheduling, 
execution,  and  commitment  can  be  applied  to  these  transactions  locally  (at  Cu). 
The  scheduler  Pu  can  generate  a  serializable  schedule  for  these  transactions  at 
Cu  and,  as  they  commit,  place  the  update  projections  into  Qu  in  the  order  of  an 
equivalent  serial  schedule.  The  reader  is  referred  to  [6]  for  methods  of  placing 
update  projections  into  Qu  in  serialization  order  when  that  order  differs  from 
the  commit-time  ordering. 

The  protocol  does  not  permit  an  update  projection  to  be  scheduled  at 
higher  security  level  back-end  databases  until  its  primary  transaction  has  been 
committed  locally.  I  n  fact,  an  update  projection  cannot  be  scheduled  at  Cv  until 
it  has  been  committed  at  all  Cu  for  u<v. 

The  protocol  processes  transactions  as  follows. 

At  each  back-end  database  Cu: 

1 .1  Primary  transactions  and  update  projections  are  received  from  the 
TFE  and  submitted  to  the  local  scheduler.  Actions  on  data  items 
are  translated  into  the  correct  actions  on  local  copies. 

1 .2  As  local  transactions  (primary  transactions  and  update 
projections)  are  committed,  a  report  of  their  commitment  is  sent 
to  the  TFE.  These  reports  are  sent  in  an  order  consistent  with  the 
serialization  order  determined  by  the  local  scheduler.  That  is.  if  Vj 
and  Vj  are  two  local  transactions,  primary  or  update,  at  Cu  and 
the  scheduler  Pu  schedules  Vj  before  Vj  in  the  local  serialization 
ordering,  then  the  commitment  report  for  Vj  is  sent  to  the  TFE 
before  that  for  Vj.  If  there  are  no  conflicts  between  Vj  and  Vjf  then 


Pu  need  not  impose  a  serialization  order  on  them,  and  the  reports 
can  be  sent  in  any  order. 


At  the TFE : 

1 1 .1  For  each  transaction  Tj  submitted  to  theTFE,  Tj  is  dispatched  to 
Cu  for  processing,  where  L(Tj)=u. 

1 1 .2  Whenever  a  commitment  report  for  Uj  is  received  from  Cu,  it  is 
added  to  the  end  of  Qu. 

1 1 .3  The  Ru  scan  the  lists  Qv  for  those  v  for  which  Cu  covers  Cv.  Ru 
will  retrieve  an  update  projection  U;  from  Qv  and  send  it  to  Cu  to 
be  executed  when  the  foil  owing  conditions  are  satisfied. 

a.  Ru  has  already  retrieved  and  dispatched  to  Cu  all  Uj  for 
which  Uj  was  serialized  before  Uj  by  Pv. 

b.  If  Cu  also  covers  Cw,  and  U;  can  eventually  appear  in  Qw, 
then  it  does  appear  in  Qw. 


The  crux  of  the  protocol  is  1 1 .3  because  it  controls  the  order  in  which  the 
primary  transactions  and  update  projections  are  distributed  to  the  back-end 
databases  for  processing  by  holding  the  submission  of  an  update  transaction 
until  all  preceding  updates  have  been  submitted.  It  is  important  to  understand 
how  this  step  can  be  performed  by  an  untrusted  Ru. 

1 1 .3.a  is  possible  because  Uj  and  Uj  arise  from  transactions  Tj  and  Tj  for 
which,  say,  L(T;)<L(Tj)=v.  Thus  the  primary  transaction  Tj  obtains  a 
serialization  order  with  either  the  primary  transaction  Tj  or  the  update 
projection  U;  from  Pv.  In  either  case,  Qv  lists  Uj  and  Uj  in  the  required  relative 
serialization  order  and  these  lower  security  level  lists  are  visible  to  Ru.  The 
order  established  at  Qv  is  maintained  as  the  updates  migrate  upward  following 
the  security  lattice  ordering.  II  ,3.b  is  possible  because  if  U,  appear  in  some 
Qv  where  Cu  covers  Cv  and  Cu  also  covers  Cw,  then  Ru  can  detect  whether  Uj 
will  eventually  appear  at  Cw.  Suppose  Uj  arises  from  the  primary  transaction 
Tj.  Then  U;  will  eventually  appear  at  Cw  if  and  only  if  w>L(T;).  Ru  can  know 
the  structure  of  the  security  lattice  below  its  own  level,  which  is  sufficient  to 
detect  the  required  condition. 


Note:  As  previously  noted,  a  partially  ordered  set  (poset)  of  security 


classes  can  be  used  rather  than  a  lattice  of  security  classes  at  the  cost  of 
adding  additional  processing  to  the  protocol.  To  do  this,  topologically  sort  the 
security  poset  obtaining  a  global  linear  ordering  of  the  security  classes.  For 
each  Cu,  this  imposes  a  linear  ordering  on  the  Cv  that  are  covered  by  Cu.  We 
now  add  condition  c  to  Step  1 1 .3 

II.3.C.  If  Uj  in  Cv  and  Uj  in  Cw  can  both  be  retrieved  by  Ru,  and  v 

precedes  w  in  the  global  linear  order,  then  Ru  retrieves  U;  before 

Ui 

This  is  necessary  because  with  a  security  poset,  the  following  situation 
could  arise.  Suppose  both  Cu  and  Cv  cover  Cy  and  Cz  (this  is  not  possible  with 
a  security  lattice).  Further  suppose  Ux  is  in  Qy  and  U2  is  in  Qz,  and  they  both 
satisfy  conditions  to  be  retrieved  by  both  Ru  and  Rv.  1 1 .3.c  then  determines  the 
order  in  which  they  will  be  retrieved,  preventing  the  possibility  of  inconsistent 
serialization  orders  being  forced  at  higher  security  levels. 

As  mentioned  earlier,  the  replicated  architecture  must  pay  the  price  of 
maintaining  the  consistency  of  the  replicated  data.  In  this  protocol,  the  price  is 
paid  in  two  ways.  First,  there  is  the  overhead  of  maintaining  the  lists  in  the 
TFE  in  terms  of  both  the  space  required  and  the  added  processing.  Second, 
because  updates  are  delayed,  and  the  delay  increases  as  the  distance  from  the 
primary  transaction's  security  level  to  higher  levels  increases,  transactions  at 
higher  security  levels  may  read  data  that  may  not  be  current. 


4.  PROOF  OF  CORRECTNESS 


For  the  proof  of  correctness  of  the  protocol,  the  definition  of  the  protocol 
will  be  modified  slightly  for  the  sake  of  mathematical  convenience.  The 
redefinition  does  not  affect  the  concurrency  of  operations  specified  by  the 
protocol . 

The  modification  eases  the  mathematical  proof  by  explicitly  accounting 
for  the  existence  of  read-only  transactions  in  the  execution  of  a  set  of 
transactions.  Because  read-only  transactions  have  an  empty  update  projection, 
there  is  no  need  to  record  them  in  the  Qu,  since  the  information  there  is  used 
only  to  correctly  propagate  updates.  Consequently,  the  serialization 
information  for  read-only  transactions  is  not  maintained  by  the  system,  nor  is 
it  necessary  for  the  correctness  of  the  protocol.  For  purposes  of  the  proof  of 
correctness,  it  would  be  convenient  if  it  did.  Therefore,  for  the  proof,  Qu  will 
not  only  contain  the  update  projections  of  transactions  executed  and  committed 
at  the  security  level  of  Qu  and  below,  but  it  will  also  contain  a  marker 
corresponding  to  read-only  transactions  that  were  executed  and  committed  at 
the  lower  levels.  For  the  sake  of  the  proof,  then,  read-only  transactions  will 


have  update  projections  that  serve  solely  to  mark  their  position  in  the 
serialization  ordering  of  all  transactions.  These  update  projections  propagate 
through  the  Qu  just  as  if  they  were  non-empty. 

One  other  artifice  is  necessary  if  the  security  lattice  S  has  no  maximal 
element.  One  is  simply  created  and  added  to  the  lattice,  and  will  be  designated 
by  t.  No  back-end  database  need  exist  for  this  artificial  security  level,  but  only 
the  list  Qt.  If  S  already  has  a  maximal  element,  no  additional  element  is  required. 

Let  U=-{Uj  TjeT}be  the  set  of  all  update  projections,  including  the  null 
ones  for  the  read-only  transactions,  and  let  U*  be  the  set  of  all  strings  from  U. 
Then  for  each  pair  of  security  classes  u  and  v  of  S,  for  which  u>v,  there  is  a 
projection  7tuv:U*-^>U*  that  is  defined  as  follows. 

(1)  if  L(Tj)<v 

(2)  7tuv(Uj)=A,  the  null  string,  otherwise. 

(3)  Extend  tiuv  to  U*  by  recursive  definition. 


Lemma.  If  u  and  v  are  in  S,  with  u>v,  then  the  serial  histories  associated 
with  tcuv(Qu)  and  Qv  are  view  equivalent. 

Proof.  The  proof  is  by  induction  on  the  minimal  length  n  of  a  path  from  u  tov 
in  the  lattice  S.  The  result  is  trivial  for  n=l,  since  if  Cu  covers  Cv,  then  the 
order  of  conflicting  operations  in  Qv  is  the  same  as  the  order  in  which  they  are 
inserted  into  Qu  by  the  condition  imposed  on  the  back-end  schedulers.  If  the 
length  of  the  minimal  path  from  u  tov  is  n>l,  find  w  for  which  u>w>v.  Then 
the  path  lengths  from  u  tow  and  from  w  tov  are  smaller  than  n,  so  the 
induction  hypothesis  is  true  for  these  paths.  Thus  Qw  is  view  equivalent  to 
Jiuw(Qu)-  and  Qv  is  view  equivalent  to  nwv(QJ.  Since  7iuv=itwv°JiUw-  the  result 
follows. 

In  particular,  the  serialization  order  for  all  transactions  that  is  specified 
by  Qt,  where  t  is  the  maximal  class  in  S,  is  consistent  with  the  serialization 
orderings  at  each  back-end  database.  The  one-copy  serial  history  that 
corresponds  to  this  ordering,  say  J  ,  will  be  shown  to  be  equivalent  to  the 
replicated  data  history  produced  by  the  protocol. 

As  an  intermediate  step  to  facilitate  the  proof,  let  H  be  the  replicated 
data  history  produced  by  the  protocol,  and  let  G  be  the  history  obtained  from 
H  by  topologically  sorting  the  security  lattice  and  putting  the  serial  histories  of 
the  Cu,  as  specified  by  the  Qu,  sequentially  in  this  topological  order. 

Lemma.  G  and  H  are  view  equivalent  as  replicated  data  histories. 

Proof.  Clearly  G  and  H  have  the  same  operations.  Since  reads-from 
relationships  and  final  writes  are  properties  local  to  each  back-end  database, 


these  local  properties  are  preserved  in  the  structure  of  H.  That  is,  if  Tj  reads- 
xu-from  Tj  in  H,  then  Tj  reads-xu-from  Tj  in  G  as  well.  A  similar  statement 
holds  for  final  writes. 

Theorem.  H  is  1SR. 

Proof.  Since  H  is  view  equivalent  to  G,  it  suffices  to  show  that  G  is  1SR. 

Claim  that  G  is  equivalent  to  the  one-copy  history  J  . 

1)  Suppose  wjx]  is  a  final  write  of  x  in  J  .  Then  if  Wj[xt]  is  not  a 
final  write  of  xt  in  G,  there  is  a  Tk  for  which  Wj[xt]<wk[xt].  Then 
Uj  precedes  Uk  in  G,  and  so  also  in  Qt.  But  then  Tj  precedes  Tk  in 
J  ,  a  contradiction.  Hence  Wj[xt]  is  a  final  write  of  xt  in  G. 

2)  Suppose  that  Tj  reads-x-from  T;  in  G,  so  that  for  some  u, 
Wj[xu]<rj[xu]  and  no  other  transaction  at  Cu  writes  xu  between 
these  operations.  Notice  that  u=L(Tj),  but  L(x)=L(Tj)  may  be 
strictly  dominated  by  u.  If  Tj  does  not  read-x-from  T;  in  J  ,  then 
there  is  a  Tk  for  which  Wj[x]<wk[x]<rj[x].  Then  in  the  serial 
history  J  ,  Tj  precedes  Tk  which  precedes  Tj.  SinceTj  and  Tk  both 
write  x,  L(Tj)=L(Tk)  which  is  dominated  by  u.  Since  jrtu(Qt) 
specifies  a  serialization  order  that  is  view  equivalent  to  that  of  Qu, 
Uj  precedes  Uk  precedes  Uj  in  Qu,  that  contradicts  that  Tj  reads- 
xu-from  Tj. 

Conversely,  suppose  Tj  reads-x-from  Tj  in  J  .  Let  u=L(Tj)  and 
v=L(Tj)=L(x),  and  suppose  Tj  does  not  read-x-from  Tj  in  G.  Then 
there  is  a  Tk,  L(Tk)=v,  for  which  Wj[xu]<wk[xu]<rj[xu].  It  follows 
that  Uj  precedes  Uk  precedes  Uj  in  Qu  and  thus  also  in  J  , 
contradicting  that  Tj  reads-x-from  T;  in  J  . 


5.  GARBAGE  COLLECTION  AND  RECOVERY 


In  implementing  the  protocol  as  described,  the  size  of  the  lists,  theQu, 
can  become  arbitrarily  large.  This  may  be  wasteful  of  storage  as  well  as 
increase  the  execution  time  for  scanning  the  Qu  by  Ru.  I  n  order  to  remedy  this 
situation,  some  form  of  garbage  collection  should  be  included  to  maintain  the 
Qu  at  a  reasonable  size. 

The  security  policy  does  not  allow  Ru  to  access  information  that  would 
indicate  whether  or  not  a  particular  U;  must  be  kept  for  future  use  by  the 
protocol,  as  this  depends  on  information  known  only  at  higher  security  levels. 
Therefore,  garbage  collection  requires  that  trusted  mechanisms  be  used.  The 


earliest  point  at  which  a  particular  Uj  may  be  discarded  from  Qu  is  when  U; 
has  been  retrieved  from  it  (and  dispatched  to  the  appropriate  back-end 
database)  by  all  the  Rv  for  which  Cv  covers  Cu. 

T rusted  components  could  be  built  to  perform  the  deletions  at  this  point, 
but  would  be  inordinately  complex  for  the  task.  A  more  likely  approach  would 
be  to  wait  until  a  particular  U;  is  inserted  into  Qt  (where  t  is  the  maximum 
class  in  the  security  lattice).  I  n  fact,  this  may  be  the  only  reason  for 
maintaining  Qt  (other  than  to  simply  the  proof  of  correctness),  since  it  is 
otherwise  unnecessary.  A  relatively  simple  trusted  mechanism  could  then 
remove  U*  from  all  of  the  relevant  Qu.  Such  a  mechanism  can  be  invoked  at 
regular  intervals.  Doing  garbage  collection  at  the  checkpoints  taken  for 
recovery  purposes  may  be  sufficient. 

As  for  recovery,  the  back-end  databases  have  their  own  recovery 
managers,  so  that  the  only  concern  is  the  recovery  of  the  contents  of  the 
dynamic  data  structures  in  theTFE.  The  recovery  scheme  to  accomplish  this 
is  straightforward  and  quite  similar  to  what  is  generally  used  for  databases.  A 
log  is  maintained  in  the  stable  storage  corresponding  to  security  level  u.  The 
log  for  security  level  u  can  be  located  on  the  same  hardware  as  the  back-end 
database  Cu  to  maintain  security  of  the  recovery  logs.  Alternatively,  a 
collection  of  single  level  logs  could  be  maintained  in  the  stable  storage 
dedicated  to  theTFE.  Whenever  Ru  receives  an  update  report  from  a  back-end 
database  and  adds  it  to  Qu,  a  log  entry  is  created  and  written  to  the  log  in 
stable  storage.  If  theTFE  should  fail,  the  logs  can  be  used  to  reconstruct  the 
Qu 

I  n  addition,  as  for  databases  in  general,  a  checkpoint  can  be  taken, 
recording  the  state  of  the  whole  DBS.  Performing  the  garbage  collection 
function  at  this  point  and  pruning  the  logs  of  any  unnecessary  entries  reduces 
the  amount  of  data  that  is  stored. 

After  a  crash,  recovery  is  accomplished  by  restoring  the  state  at  the  last 
checkpoint  and  using  the  logs  to  update  the  DBS  to  the  point  of  failure.  The 
proposed  technique  requires  little  trusted  code. 


6.  CONCLUSION 

The  replicated  architecture  for  MLS-DBSs  has  the  potential  to  provide 
performance  significantly  better  that  the  kernelized  architecture  design  since 
the  work  performed  for  a  user  during  a  single  log-in  session  takes  place  within 
a  single,  conventional  database  system.  What  is  needed  to  make  the  replicated 
architecture  work  is  an  untrusted  mechanism  that  maintains  database 
consistency  without  giving  up  the  potential  for  concurrent  execution  of 
database  operations.  The  protocol  presented  here  provides  this.  The  additional 
overhead  to  provide  the  consistency  control  is  not  excessive  and  relatively 
straightforward  to  implement.  Most  of  the  concurrency  control  and  recovery 


processes  are  provided  by  the  back-end  databases  themselves.  Moreover  the 
additional  code  required  for  the  management  of  the  lists  in  the  front-end  need 
not  be  trusted,  reducing  the  effort  required  for  system  assurance. 


7.  FUTURE  RESEARCH 


An  interesting  question  arose  while  doing  the  work  for  this  paper 
concerning  the  notion  of  "correctness"  for  transaction  processing  in  a  multilevel 
database  system.  The  usual  concept  of  a  database  transaction  precludes 
transactions  from  communicating  with  each  other.  I  n  this  context, 

"correctness"  of  execution  is  usually  interpreted  as  looking  to  the  user  as  if 
their  transactions  operated  one  at  a  time  in  some  order.  In  untrusted 
(ordinary)  replicated  database  systems,  this  position  is  satisfactory  and  one- 
copy  serializability  is  an  acceptable  criterion  for  "correctness".  In  the  replicated 
architecture  multilevel  case,  however,  something  more  seems  appropriate. 

Consider  the  following  example.  In  the  untrusted  situation,  a  user 
submits  the  transaction  w[x]r[x]w[y].  That  is,  the  user  writes  new  value  for 
x,  reads  it  and  performs  some  process  and  writes  a  new  value  for  y.  The  user 
is  assured  that  the  value  of  x  used  in  the  ensuing  process  is  the  one  just 
written  because  w[x]  and  r[x]  conflict  and  are  therefore  ordered  within  the 
transaction.  Now  suppose  that  x  has  a  low  security  level  and  y  a  high  one,  and 
that  the  process  that  reads  x  and  writes  y  is  a  high  security  level  analysis. 

The  user  can  no  longer  bind  the  write  and  read  operations  on  x  so  that  the 
desired  ordering  is  enforced.  In  the  multilevel  situation,  the  original 
transaction  must  be  broken  into  two  transactions,  w[x]  and  r[x]w[y],  that 
must  be  submitted  at  two  different  security  levels.  Moreover,  one-copy 
serializability  no  longer  guarantees  that  the  user's  expectations  about  the 
order  of  execution  are  realized.  In  fact  either  ordering  of  the  two  transactions 
satisfies  that  criterion,  regardless  of  which  of  the  two  transactions  is  submitted 
fi  rst. 

If  one  holds  to  the  common  practice  of  identifying  a  user  with  a  single 
level  log-on  session,  then  a  user  is  a  single  level  entity  for  whom  one-copy 
serializability  gives  a  consistent  view  of  the  database.  But  users  do  not  view 
themselves  in  this  way  in  a  multilevel  situation.  Rather,  one  usually  thinks  of 
a  person  who  can  log-in  to  the  system  at  a  number  of  security  levels,  so  that 
the  situation  described  above  can  actually  occur.  It  appears  that  some  notion  of 
multilevel  transaction  and  a  corresponding  concept  of  "correctness"  are 
required  to  extend  the  ideas  of  this  paper  to  what  users  expect  to  happen. 

This  problem  seems  to  be  related  to  a  number  of  issues  that  arise  from 
commingling  database  theory  with  that  of  computer  security.  The  distinction 


between  database  user  and  a  subject  in  a  secure  system,  as  noted  above,  seems 
to  be  at  least  part  of  the  problem.  I  nvestigation  of  this  problem  and  related 
issues  will  be  the  subject  of  future  work. 
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